Salut à tous,

L'épreuve d'un point de vu "algorithmie" ne me semble pas très dur ...

Mon algo  repose principalement sur des expressions régulières, mais ne semble malgré mes effort, pas  valider le défi.

Je travaille directement en Javascript la depuis  la  console du navigateur à coup de XMLHttpRequest ou de fetch donc ... a priori pas un problème de sessions.

Je recontrôle manuellement le résultat que j'obtiens pour m'assurer qu'il n'y ait pas d'erreur dans le calcul.

(1°) Les candidats sont bien traité dans l'ordre avec la gestion des homonymes.
(2°) Les configurations sont bien calculés pour chaque candidat.
(3°) Le résultat est correctement transmis (pas de souci de caractère spéciaux et ou d'encodage maladroit).

Mais ... toujours le même retour : "Ce n'est pas la bonne réponse.. Retente ta chance."

J'ai 2 choses qui me viennent à l'esprit.
Si en faisant "humainement" le calcul je parviens aux même conclusions que mon script ... suis-je moi même bugué ?
L'épreuve n'a pas eu de validation depuis Août dernier, soit depuis 5 mois,  est-ce un hasard ou y aurait-il eu un changement sur cette période
qui pourrait empêcher la validation de l'épreuve ?

Bref pour m'éviter une psychanalyse je viens poster ici pour obtenir une réponse à ces 2 questions existentielles.
Merci par avance


MeaCupla ... c'est bien un problème d'ICC ... j'ai fixé le souci ... je vous offre mes plus plates excuses pour avoir douté de l'épreuve.
En compensation, je vous offre une fraiche validation datée de ce jour

Je voudrais juste savoir, si le fait que le résultat à ce test => DNSSEC Resolver Test n'est pas bon, indique que mon serveur DNS est en mauvais état ?  

Bonsoir BON !! Au final, j'ai réussi à manier TOR,  et je n'ai pas changé ma vie pour autant   

Je n'ai pas cherché à aller au delà des sites autorisés en fait !!

[Que peux tu me dire sur mon serveur DNS au regard des copies de terminal déposées ?]

DoH, c'est DNS over HTTPS.
Ca veut dire que les requêtes et réponses DNS sont encapsulées dans une requête HTTPS. Si le serveur DNS gère le DoH, que son certificat est valide, et que tu n'autorises pas les certificats invalides, c'est tout autant sécurisé qu'une requête HTTPS classique.

DoT (DNS over TLS) c'est pareil, mais sans passer par une surcouche HTTPS. A mon sens c'est mieux, mais comme tout le monde ne jure que par HTTPS en 2024, DoT est moins utilisé

Maintenant, toutes les linux/windows devraient gérer le fait d'utiliser un DoH. En termes de serveurs DoH, si tu veux utiliser un serveur public, tu dois en avoir un paquet dispo sur internet (8.8.8.8 probablement).
Si tu veux installer un serveur DNS à toi, unbound et bind semblent prendre charge le DoH

Enjoy



The lsd

Bonsoir LSD, je te remercie pour ta réponse

En effet, j'essaie de faire ceci =>

Si tu veux installer un serveur DNS à toi, unbound et bind semblent prendre charge le DoH

NB : Je n'ai rien d'un dangereux pervers ou psychopathe du NET       j'essaie juste de comprendre certains aspects, et les appliquer ensuite.

Que peux tu me dire sur mon serveur DNS au regard des copies de terminal déposées ?  

DoH, c'est DNS over HTTPS.
Ca veut dire que les requêtes et réponses DNS sont encapsulées dans une requête HTTPS. Si le serveur DNS gère le DoH, que son certificat est valide, et que tu n'autorises pas les certificats invalides, c'est tout autant sécurisé qu'une requête HTTPS classique.

DoT (DNS over TLS) c'est pareil, mais sans passer par une surcouche HTTPS. A mon sens c'est mieux, mais comme tout le monde ne jure que par HTTPS en 2024, DoT est moins utilisé

Maintenant, toutes les linux/windows devraient gérer le fait d'utiliser un DoH. En termes de serveurs DoH, si tu veux utiliser un serveur public, tu dois en avoir un paquet dispo sur internet (8.8.8.8 probablement).
Si tu veux installer un serveur DNS à toi, unbound et bind semblent prendre charge le DoH

Enjoy

The lsd

Tu peux regarder du côté DoT DoH (DNS over TLS et DNS over https) pour les serveurs upstream

Enjoy

The lsd

Tu m'avais conseillé ceci ci dessus, en 2020, mais je n'ose pas trop m'y attaquer, ne sachant pas si cela est sans danger.
De plus, certaines pages de sites, qui donnaient des conseils, ne sont pas accessibles, les liens sont morts.

Tu m'avais de cela https://ladnet.net/installer-et-configurer-unbound-sur-debian-9

Est ce bon signe ? J'ai beau relire la totalité des messages de ce post, j'ai du mal à reproduire ce que j'avais fait il y a quelques années pour mon serveur DNS.

J'avais réussi à modifier le fichier unbound.conf, en ce sens, j'avais pris l'initiative de le sauvergarder, j'en ai donc une copie, mais que faire avec ?

Code:

james14000@james14000-MS-7982:~$ nmcli dev show | grep DNS
IP4.DNS[1]:                             127.0.0.1
IP4.DNS[2]:                             192.168.*.*
james14000@james14000-MS-7982:~$ 

Code:

james14000@james14000-MS-7982:~$ nmcli 
enp1s0: connecté à netplan-enp1s0
        "Realtek RTL8111/8168/8411"
        ethernet (r8169), *C:CC:*A:*A:**:14, hw, mtu 1500
        ip4 par défaut
        inet4 192.168.1.**/24
        route4 192.168.*.*/24 metric 100
        route4 default via 192.1**.*.* metric 100

lo: connecté (en externe) à lo
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
        inet4 127.0.0.1/8
        inet6 ::1/***

DNS configuration:
        servers: 127.0.0.1 192.1**.*.*
        interface: enp1s0

Utilisez « nmcli device show » pour obtenir des informations complètes sur les >

Consultez les pages de manuel nmcli(1) et nmcli-examples(7) pour les détails co>
lines 1-21/21 (END)

Je viens aussi de me rendre compte que certaines commandes indiquées dans ce tutot, ne fonctionnent plus sous UBUNTU 24.04, alors qu'elles fonctionnaient sur UBUNTU 18.04.

Que faire ?  

Code:

james14000@james14000-MS-7982:~$ systemd-resolve --status --no-pager
systemd-resolve : commande introuvable
james14000@james14000-MS-7982:~$ apt install unbound unbound-host dnssec-trigger 
E: Impossible d'ouvrir le fichier verrou /var/lib/dpkg/lock-frontend - open (13: Permission non accordée)
E: Impossible d'obtenir le verrou de dpkg (/var/lib/dpkg/lock-frontend). Avez-vous les droits du superutilisateur ?

Code:

james14000@james14000-MS-7982:~$ unbound-checkconf
unbound-checkconf: no errors in /etc/unbound/unbound.conf
james14000@james14000-MS-7982:~$ 

[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).]

J'avais aussi pris en compte ces conseils que voici :    

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.

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 !