DNS attaqués, configurer DNSSEC

rogn... · Le 28/02/2019, à 13:46

Brunod a écrit :

rogn... a écrit :
Brunod a écrit :
Je me demande surtout ce qu'on veut nous fourguer en douce sous couvert de passage à ces "nouvelles mesures" de sécurité.
Des mises à jour pour Windows, Mac, Android, iOS, et pour les bases de données anti-truc.
Non, je ne pense pas, une màj n'apporte rien en soi.

Sur un autre topic j'ai dit que j'avais écouté le secrétaire d'état au numérique Mounir Majoubi sur une émssion radio. Le mec prétend que l'on subit des attaques de grande ampleur et que ce ne serait du jamais vu. Pour éviter ça, il faut selon lui mettre à jour Windows, Mac, Android, iOS, et les bases de données anti-virus.
Ça ne va pas plus loin que ça.

Brunod · Le 28/02/2019, à 14:24

Mwoui, je m'en réfère plutôt au lien du post https://forum.ubuntu-fr.org/viewtopic.p … #p22060071 beaucoup plus fiable que le porte-parole que tu évoques qui d'ailleurs ne fait que répéter ce qu'on a entendu ces derniers jours; alors que visiblement il ne semble y a voir aucune attaque particulière, surtout que cela relayait une info datant de plus de 15 jours au moment où elle a été reprise
https://www.zdnet.fr/actualites/attaque … 1551184681

https://www.zdnet.fr/actualites/selon-l … 1551093984

Ca sort le 23/2, alors que ça date de janvier...
"In January, security company FireEye revealed that hackers likely associated with Iran were hijacking DNS records on a massive scale, by rerouting users from a legitimate web address to a malicious server to steal passwords. "
Source :
https://techcrunch.com/2019/02/23/icann … CvOW4lurfI

abecidofugy · Le 01/03/2019, à 09:07

nam1962 a écrit :

[Edit], pour vérifier un domaine :
dig +dnssec SOA ubuntu-fr.org
Il doit y avoir "ad" dans les réponses de flag --> https://serverfault.com/questions/15401 … ing-dnssec

Salut,

Si je comprends bien, Ubuntu-fr n’a pas le DNSSEC activé ?

dig +dnssec SOA ubuntu-fr.org

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> +dnssec SOA ubuntu-fr.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41289
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
;; QUESTION SECTION:
;ubuntu-fr.org.                 IN      SOA

;; ANSWER SECTION:
ubuntu-fr.org.          6776    IN      SOA     a.dns.gandi.net. hostmaster.gandi.net. 1527509138 10800 3600 604800 10800

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Mar 01 09:04:08 CET 2019
;; MSG SIZE  rcvd: 104

Je ne vois pas de ad.

Sinon, à : http://www.dnssec-or-not.com/
J'ai :
Sigh... the test indicates you are NOT protected.

C’est bon ma box qui n'assure pas ?

Merci et belle journée.

Dernière modification par abecidofugy (Le 01/03/2019, à 09:09)

bruno · Le 01/03/2019, à 09:26

Tu as bien compris ubuntu-fr.org n'utilise pas DNSSEC, pas IPv6, …

Pour l'autre question quel résolveur utilises-tu ?

maxire · Le 01/03/2019, à 09:43

C'est tout de même étrange, pourquoi la validation dnssec n'est-elle pas activée par défaut côté client ?
Je viens de la mettre en place en activant le cache dns de dnsmasq sous NetworkManager et cela semble rouler.

nam1962 · Le 01/03/2019, à 09:46

Comment as-tu fait ?

maxire · Le 01/03/2019, à 09:54

@nam1962, j'imagine que ta question est destinée à abecidofugy.

abecidofugy · Le 01/03/2019, à 10:00

bruno a écrit :

Pour l'autre question quel résolveur utilises-tu ?

C’est quoi la ligne de commande pour le savoir, ou dans le GUI ?

[/mode boulet]

grandtoubab · Le 01/03/2019, à 10:16

abecidofugy a écrit :

bruno a écrit :
Pour l'autre question quel résolveur utilises-tu ?
C’est quoi la ligne de commande pour le savoir, ou dans le GUI ?
[/mode boulet]

nmcli

pour tracer les réponses

dig +trace ubuntu.com

pour l'identité des root.server
https://www.iana.org/domains/root/servers

Exemple

;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) mon cache dnsmasq
;; Received 1198 bytes from 199.9.14.201#53(b.root-servers.net) le serveur racine University of Southern California (ISI)
;; Received 636 bytes from 192.35.51.30#53(f.gtld-servers.net) mon resolver Verisign tel qu'indiqué par https://dnslytics.com/ip/192.35.51.30

ubuntu.com. 600 IN A 91.189.94.40
ubuntu.com. 600 IN NS ns1.canonical.com.
ubuntu.com. 600 IN NS ns2.canonical.com.
ubuntu.com. 600 IN NS ns3.canonical.com.
;; Received 167 bytes from 91.189.91.139#53(ns3.canonical.com) Ubuntu est chez Canonical

Dernière modification par grandtoubab (Le 01/03/2019, à 10:45)

abecidofugy · Le 01/03/2019, à 11:40

enp0s3: connecté to Nouvelle connexion : 802-3-ethernet
        "Intel 82540EM Gigabit Ethernet Controller (PRO/1000 MT Desktop Adapter)"
        ethernet (e1000), 08:00:27:90:50:5E, hw, mtu 1500
        ip4 par défaut
        inet4 192.168.1.45/24
        route4 0.0.0.0/0
        route4 192.168.1.0/24
        route4 169.254.0.0/16
        inet6 fe80::7459:844a:fcf0:7638/64
        route6 ff00::/8
        route6 fe80::/64
        route6 fe80::/64

lo: non-géré
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
        servers: 192.168.1.1
        interface: enp0s3

Euh… c'est 192.168.1.1 ?

grandtoubab · Le 01/03/2019, à 11:46

abecidofugy a écrit :

enp0s3: connecté to Nouvelle connexion : 802-3-ethernet
        "Intel 82540EM Gigabit Ethernet Controller (PRO/1000 MT Desktop Adapter)"
        ethernet (e1000), 08:00:27:90:50:5E, hw, mtu 1500
        ip4 par défaut
        inet4 192.168.1.45/24
        route4 0.0.0.0/0
        route4 192.168.1.0/24
        route4 169.254.0.0/16
        inet6 fe80::7459:844a:fcf0:7638/64
        route6 ff00::/8
        route6 fe80::/64
        route6 fe80::/64

lo: non-géré
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
        servers: 192.168.1.1
        interface: enp0s3

Euh… c'est 192.168.1.1 ?

oui c'est ta box, rien n'est configuré sur ton PC

abecidofugy · Le 01/03/2019, à 11:59

grandtoubab a écrit :

oui c'est ta box, rien n'est configuré sur ton PC

J'ai changé pour ça : 80.67.169.12

fdn.fr

inbox · Le 01/03/2019, à 12:09

Salut,

Pour vérifier les DNS actifs sur le PC, cette commande filtre le retour :

sudo nmcli device show | grep DNS

A+

maxire · Le 01/03/2019, à 12:26

Quelque chose d'assez drôle, je viens de vérifier plusieurs sites français, www.liberation.fr, www.lepoint.fr, www.lemonde.fr, orange.fr, imap.orange.fr, pop3.orange.fr; aucun d'entre eux ne propose de validation dnssec.
@abecidofugy, ce n'est pas une question de paramétrage de serveur DNS à utiliser mais de paramétrage du client envoyant les requêtes DNS.
Si tu utilises networkmanager il est utile de passer via un cache dns local comme dnsmasq ou systemd-resolved, il faut alors configurer ces résolveurs locaux pour qu'ils demandent une validation dnssec.
Grantoubab a d'alleurs donné comment configurer networkmanager/dnsmasq pour activer dnssec dans un des précédents messages de ce fil.
En ce qui concerne le paramétrage de systemd-resolved ce n'est pas très clair.

maxire · Le 29/03/2019, à 10:15

Salut,

Je reprends ce fil avec une configuration mettant en place dnssec via systemd-resolved sous Ubuntu 18.04 tout en utilisant les serveurs DNS de FDN:

bionic@k72f-J48-ubgnome:~$ cat /etc/systemd/resolved.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
#DNS=
DNS=80.67.169.12 80.67.169.40 2001:910:800::12 2001:910:800::40
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
DNSSEC=allow-downgrade
#Cache=yes
#DNSStubListener=yes
bionic@k72f-J48-ubgnome:~$

ionic@k72f-J48-ubgnome:~$ systemd-resolve --status --no-pager
Global
         DNS Servers: 80.67.169.12
                      80.67.169.40
                      2001:910:800::12
                      2001:910:800::40
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 3 (wls1)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: no
         DNS Servers: 192.168.1.1
          DNS Domain: home

Link 2 (ens5)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes
bionic@k72f-J48-ubgnome:~$

Cette configuration permet de résoudre les noms de domaines locaux en l'occurrence via le serveur dns d'une livebox qui ne gère pas dnssec tout en utilisant les serveurs dns de FDN pour les domaines non locaux.
La connexion active est wls1, dnssec est indiqué comme non supporté par le serveur DNS local 192.168.1.1 mais supporté par les serveurs de FDN, systemd-resolved utilise automatiquement dnssec si les serveurs dns le proposent.

Résolution en local :

bionic@k72f-J48-ubgnome:~$ systemd-resolve fixe
fixe: 192.168.1.12
      (fixe.home)

-- Information acquired via protocol DNS in 8.0ms.
-- Data is authenticated: no
bionic@k72f-J48-ubgnome:~$

Résolution inverse en local :

bionic@k72f-J48-ubgnome:~$ systemd-resolve 192.168.1.12
192.168.1.12: fixe.home

-- Information acquired via protocol DNS in 8.3ms.
-- Data is authenticated: no
bionic@k72f-J48-ubgnome:~$

Résolution www :

bionic@k72f-J48-ubgnome:~$ systemd-resolve sigok.verteiltesysteme.net
sigok.verteiltesysteme.net: 134.91.78.139

-- Information acquired via protocol DNS in 250.9ms.
-- Data is authenticated: yes
bionic@k72f-J48-ubgnome:~$

Résolution inverse www :

bionic@k72f-J48-ubgnome:~$ systemd-resolve 134.91.78.139
134.91.78.139: derp.vs.uni-due.de
               derp.vs.uni-duisburg-essen.de

-- Information acquired via protocol DNS in 502.5ms.
-- Data is authenticated: no
bionic@k72f-J48-ubgnome:~$

Cette configuration permet de configurer les dns tout en laissant les connexions définies via Networkmanager en DHCP automatique, donc en utilisant le serveur dns local fourni par la box tout en n'utilisant pas les serveurs DNS du fournisseur de service internet.
Cela fonctionne avec Orange.

Plus d'information sur l'activation de DNSSEC :

bionic@k72f-J48-ubgnome:~$ systemd-resolve --statistics
DNSSEC supported by current servers: yes

Transactions
Current Transactions: 0
  Total Transactions: 5139

Cache
  Current Cache Size: 39
          Cache Hits: 1281
        Cache Misses: 3611

DNSSEC Verdicts
              Secure: 75
            Insecure: 137
               Bogus: 0
       Indeterminate: 0
bionic@k72f-J48-ubgnome:~$

F50 · Le 03/04/2019, à 13:21

Salut,

@ maxire : Merci pour les précisions qui m'ont évité d'aller chercher plus loin. Par contre, quelques détails :

1. Est-ce volontaire les "bionic@k72f-J48-ubgnome:~$2 à la fin des fichiers .conf pour le retour de "systemd-resolve fixe" ?
Ici, si je fais "systemd-resolve fixe" il retourne : fixe: resolve call failed: All attempts to contact name servers or networks failed.

Mais si je change <fixe> par mon <hostname> ça fonctionne.

2. Un truc me dérange, si tu ne mets pas explicitement les FallbackDNS= " " /etc/resolv.conf retoune :

domain home
search home
nameserver 8.8.8.8
nameserver 8.8.4.4

Pas top vu que le but est justement de les éviter !

maxire · Le 03/04/2019, à 13:32

Salut F50,

Réponses :
1 - C'est juste l'invite de commandes suivante et ce que j'affiche ce ne sont pas que des fichiers de configurations mais des résultats de commandes, je ne comprends pas ce que tu as tenté.
2 - Je ne comprends pas ce que tu veux dire, ce que tu as fait, d'autant que je ne me suis jamais préoccupé de /etc/resolv.conf qui devrait être :

bionic@k72f-J48-ubgnome:~$ cat /etc/resolv.conf
# Generated by NetworkManager
search home k72f-J48-ubgnome.home
nameserver 127.0.0.53
bionic@k72f-J48-ubgnome:~$

si tu as bien activé systemd-resolved.

Dernière modification par maxire (Le 03/04/2019, à 13:33)

F50 · Le 03/04/2019, à 14:11

Salut maxire,

1. "C'est juste l'invite de commandes suivante", ça prête à confusion...
2. Ben, tu devrais car c'est LE FICHIER utiliser par tous les programmes pour la résolurtion DNS. Le miens est différent car je n'utilise pas NM, qui chez toi a écrit (comme chaque network manager le fait par défaut) :
# Generated by NetworkManager

D'où le "nameserver 127.0.0.53" chez toi contrairement à ici :

domain home
search home
nameserver 8.8.8.8
nameserver 8.8.4.4

Ces nameserver 8.8.8.8 & 8.8.4.4 doivent êtres un "default" de systemd-resolved si l'option FallbackDNS= " " est vide ou commentée dans /etc/systemd/resolved.conf et que le network manager installé ne résout pas les DNS de son propre chef.

Edit : Voici le pourquoi de la différence entre ton 127.0.0.53 et mes 8.8.8.8 & 8.8.4.4 dans resolv.conf :

DNS

https://wiki.archlinux.org/index.php/Sy … figuration

Dernière modification par F50 (Le 03/04/2019, à 14:32)

maxire · Le 03/04/2019, à 15:01

La dernière invite de commandes indique simplement au lecteur que l'affichage des résultats est complet, c'est la norme de ce forum.

En disant, je ne me suis jamais préoccupé de /etc/resolv.conf je faisais référence à mon message, de plus tu peux parfaitement te passer de /etc/resolv.conf, tout dépend de la configuration de nsswitch et dnssd ou mdns/SD ne l'utilisent pas pour la résolution locale.

Au moins as-tu lancé le service systemd-resolved ?

Je ne connais pas ta configuration réseau exacte, les serveurs DNS de Google ne sortent pas de nulle part.
Je crois que tu es parti un peu en hors sujet, ce fil est consacré à DNSSEC et l'exemple que je donne est l'utilisation de systemd-resolved en cache DNS de NetworkMAnager avec une configuration DNS shuntant celle obtenue via le client DHCP (dhclient, dhcpcd ou le client interne) utilisé par NetworkManager.

Ton /etc/resolv.conf est plus que bizarre avec les paramétrages domain home et search home sans même un serveur DNS local indiqué, tu as raté un truc !

Pour les serveurs Google tu as dû également rater un truc et sans ta configuration complète je ne peux rien te conseiller et ce n'est d'ailleurs pas l'objet de ce fil.

Dernière modification par maxire (Le 03/04/2019, à 15:26)

grandtoubab · Le 03/04/2019, à 16:04

Une doc de l'ANSSI
https://www.ssi.gouv.fr/uploads/2014/05 … si_1.3.pdf

https://www.ssi.gouv.fr/uploads/2014/05/guide_dns_fr_anssi_1.3.pdf a écrit :

La recommandation R4
Choisir un bureau d'enregistrement prenant en charge DNSSEC

Dernière modification par grandtoubab (Le 03/04/2019, à 16:06)

F50 · Le 03/04/2019, à 18:47

@ maxire : lancé "service systemd-resolved" ?

systemd-resolve --status --no-pager
Global
       LLMNR setting: yes
MulticastDNS setting: yes
  DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes
  Current DNS Server: 80.67.169.12
         DNS Servers: 80.67.169.12
                      80.67.169.40
                      2001:910:800::12
                      2001:910:800::40
Fallback DNS Servers: 1.1.1.1
                      9.9.9.10
                      2606:4700:4700::1111
                      2620:fe::10
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 2 (wlp6s0)
      Current Scopes: LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: no
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes

Concernant : "Pour les serveurs Google tu as dû également rater un truc et sans ta configuration complète je ne peux rien te conseiller et ce n'est d'ailleurs pas l'objet de ce fil."

As-tu lu le lien que j'ai mis ?

https://wiki.archlinux.org/index.php/Sy … figuration

Fallback

If systemd-resolved does not receive DNS server addresses from the network manager and no DNS servers are configured manually then systemd-resolved falls back to the fallback DNS addresses to ensure that DNS resolution always works.
[b]Note: The fallback DNS are in this order: Cloudflare, Quad9 (without filtering and without DNSSEC) and Google[/b]; see the systemd PKGBUILD where the servers are defined.

The addresses can be changed by setting FallbackDNS= in resolved.conf(5). E.g.:

Pour ce qui est de mon /etc/revolv.conf plus que bizarre, c'est probablement connman qui y met du sien. Je vais regarder ça de prêt...

maxire · Le 03/04/2019, à 19:57

Euh, non ton problème n'a rien à voir avec les serveurs de secours (fallback servers) car si je lis cet extrait de ta configuration systemd-resolved :

Fallback DNS Servers: 1.1.1.1
                      9.9.9.10
                      2606:4700:4700::1111
                      2620:fe::10

Je ne vois aucun serveur Google !

Je ne sais pas comment a été généré ton /etc/resolv.conf mais je crois qu'il faut chercher par là,.
Je ne connais pas conman, tiens-t-il compte de systemd-resolved ?

F50 · Le 04/04/2019, à 06:33

C'est rentré dans l'ordre après un reboot alors que j'avais relancé tous les services.

Il n'y avait plus de serveur googoole car je l'avais déjà enlevé mais resolv.conf continuait à l'indiquer. Si l'on ne désire pas ces fallback DNS, il suffit de laisser FallbackDNS= vide ou garder ceux au choix.

Connman est particulier car il utilise ses propres DNS proxy mais il y a moyen de stopper cette fonction (voir wiki arch). Maintenant il génére resolv.conf mais avec les DNS indiqué par systemd-resolved.

maxire · Le 04/04/2019, à 07:32

FD50, manifestement tu utilises Archlinux, la version de systemd qu'utilise Archlinux n'est pas du tout la même que celle de Ubuntu.
systemd Ubuntu n'utilise aucun fallback DNS servers, de ce que je vois.
Les informations données dans le wiki de Archlinux ne sont pas forcément valables pour Ubuntu.
De plus je persiste dans mon idée que l'appartition des serveurs Google dans ton /etc/resolv.conf vient de la configuration de connman et non de sytemd-resolved.
Et oui c'est vrai les options par défaut de systemd-resolved peuvent être modifiées via /etc/systemd/resolved.conf.

F50 · Le 04/04/2019, à 08:21

Oui j'utilise Arch et je suppose que les versions systemd divergent mais globalement c'est le même fonctionnement et options, Buntu comme je l'imagine, rajouter une couche pour "faciliter" la prise en mains.

Les infos du wiki Arch sont souvent plus à jours et détaillées que celle de Buntu à part pour les emplacements qui varient selon les distros.

Il y a du avoir un brouillon à la relance des services d'où les serveurs Googoole mais c'est effectivement Connman qui génére resovl.conf car je ne l'ai pas symlinké avec systemd.resolved pour pas que ce fichier soit accaparé par un logiciel exlusive (c'est détaillé dans la doc Arch).

Connman passe par le fichier /etc/systemd/resolved.conf pour générer resolv.conf sans imposer ces DNS proxy, c'est le but et ça fonctionne :

systemd-resolve --status --no-pager
Global
       LLMNR setting: yes
MulticastDNS setting: yes
  DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes
  Current DNS Server: 80.67.169.12
         DNS Servers: 80.67.169.12
                      80.67.169.40
                      2001:910:800::12
                      2001:910:800::40
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 2 (wlp6s0)
      Current Scopes: LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: no
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 28/02/2019, à 13:46

Re : DNS attaqués, configurer DNSSEC

#27 Le 28/02/2019, à 14:24

Re : DNS attaqués, configurer DNSSEC

#28 Le 01/03/2019, à 09:07

Re : DNS attaqués, configurer DNSSEC

#29 Le 01/03/2019, à 09:26

Re : DNS attaqués, configurer DNSSEC

#30 Le 01/03/2019, à 09:43

Re : DNS attaqués, configurer DNSSEC

#31 Le 01/03/2019, à 09:46

Re : DNS attaqués, configurer DNSSEC

#32 Le 01/03/2019, à 09:54

Re : DNS attaqués, configurer DNSSEC

#33 Le 01/03/2019, à 10:00

Re : DNS attaqués, configurer DNSSEC

#34 Le 01/03/2019, à 10:16

Re : DNS attaqués, configurer DNSSEC

#35 Le 01/03/2019, à 11:40

Re : DNS attaqués, configurer DNSSEC

#36 Le 01/03/2019, à 11:46

Re : DNS attaqués, configurer DNSSEC

#37 Le 01/03/2019, à 11:59

Re : DNS attaqués, configurer DNSSEC

#38 Le 01/03/2019, à 12:09

Re : DNS attaqués, configurer DNSSEC

#39 Le 01/03/2019, à 12:26

Re : DNS attaqués, configurer DNSSEC

#40 Le 29/03/2019, à 10:15

Re : DNS attaqués, configurer DNSSEC

#41 Le 03/04/2019, à 13:21

Re : DNS attaqués, configurer DNSSEC

#42 Le 03/04/2019, à 13:32

Re : DNS attaqués, configurer DNSSEC

#43 Le 03/04/2019, à 14:11

Re : DNS attaqués, configurer DNSSEC

#44 Le 03/04/2019, à 15:01

Re : DNS attaqués, configurer DNSSEC

#45 Le 03/04/2019, à 16:04

Re : DNS attaqués, configurer DNSSEC

#46 Le 03/04/2019, à 18:47

Re : DNS attaqués, configurer DNSSEC

#47 Le 03/04/2019, à 19:57

Re : DNS attaqués, configurer DNSSEC

#48 Le 04/04/2019, à 06:33

Re : DNS attaqués, configurer DNSSEC

#49 Le 04/04/2019, à 07:32

Re : DNS attaqués, configurer DNSSEC

#50 Le 04/04/2019, à 08:21

Re : DNS attaqués, configurer DNSSEC

Pied de page des forums