[DNS] Échapper aux DNS menteurs ?

[Krapace]

Perso ça m'a prit plus de temps de monter une machine de test et la régler que de le mettre en dure chez moi.

 

Et trois commandes et deux edit de .conf ça fonctionne...

 

Mais faut encore que je vérifie que l'ipv6 passe bien et que je soit pas limité a l'ipv4

[John Shaft]

J'ai fait des tests de perfs  (latence sur les réponses) sur ma ligne ADSL (pourrie) ce week-end. Me reste encore à mettre en forme et écrire une bafouille.

[Krapace]

Je pense qu’après une bonne semaine d'utilisation le cache est bien rempli et réduit les latences.

[John Shaft]

Nope, le cache se vide assez vite (merci les TTL de 600 (Google) voir 60 secondes de Twitter qui forcent à refaire des requêtes fréquentes - bon heureusement les enregistrements NS ont souvent un TTL plus long mais pas tout le temps). Pour vraiment garder un cache à jour, il faut requêter en permanence les domaines. Le prefetch permet de pallier en parti à ça, mais il ne permet de pallier les longues phases où l'on va dormir

 

En clair, mon test portait sur environ 1000 réponses (ça fait un peu plus de 1000 requêtes - mais là j'ai pas compté ) sur un cache de 3-4 jours :

 

d <=50ms -> 480 requêtes

50ms< d <=100ms -> 113

100ms< d <=200ms -> 77

200ms< d <=300ms -> 63

d >300ms -> 274

 

où d correspond à la valeur dns.time dans Wireshark, soit la durée entre la dernière question d'une requête et l'arrivée de la réponse à la requête. Testé sous Linux car sous Windows, si la réponse n'est pas arrivée au bout d'une seconde, il renvoie la même requête et c'est donc cette dernière qui est prise en compte par Wireshark, ce qui fausse les résultat

 

En clair, 48% des requêtes tapent dans le cache. Faut que je vérifie, mais la manie de Firefox à faire des demandes fréquentes sur les onglets ouverts joue et 11% sont sous les 100ms (ce qui indique grosso modo que tu connais le serveur à questionner). Le reste nécessite de passer par la racine ou les DNS des TLD (ce qui est plus probable)

 

 

Sur le DNS de mon FAI (OVH), même conditions de tests, 0% des requêtes sont arrivées en moins de 50ms, en revanche 70% ont pris entre 50 et 100ms.

 

Avec un cache vide, on obtient 45% de réponses à plus de 200ms (contre 33 ici). Le test que j'ai fait cache vide n'utilise néanmoins pas tout à fait la même méthodo (je l'ai fait sous Windows, avant de découvrir que cela posait problème) et n'ai donc pas fiable.

 

Bon mes résultats sont assez mauvais, je précise que ma ligne ADSL est vraiment pourri (j'ai eut du 4Mbits/1Mbits stable et un ping correct pendant 2 ans et demi et depuis début juin, je peine à avoir 3.5Mbits/400kbits avec un ping qui joue au yo-yo - ticket en cours chez le FAI )

 

Je compte bien tester sur une ligne VDSL correcte la semaine prochaine. L'idéal serait d'avoir les résultats sur un accès fibre.

 

Autre point que dont j'aimerai connaitre l'INpact est la validation DNSSEC. Combien de temps rajoute-t-elle ? Le fait que les serveurs de mon FAI ne l'utilise pas joue-t-il ?... Bon par contre, flemme de configurer un serveur ne validant pas les réponses

[Krapace]

Ce que je vient de voir pour la config de unbound me ravi !

 

 

 

local-zone: "doubleclick.net" redirect
local-data: "doubleclick.net A 127.0.0.1"
local-zone: "googlesyndication.com" redirect
local-data: "googlesyndication.com A 127.0.0.1"
local-zone: "googleadservices.com" redirect
local-data: "googleadservices.com A 127.0.0.1"
local-zone: "google-analytics.com" redirect
local-data: "google-analytics.com A 127.0.0.1"
local-zone: "ads.youtube.com" redirect
local-data: "ads.youtube.com A 127.0.0.1"
local-zone: "adserver.yahoo.com" redirect
local-data: "adserver.yahoo.com A 127.0.0.1"

[John Shaft]

Sur le site de Calomel, y a une méthode pour récupérer une liste sur le ouèbe et l'intégrer à la conf

[Krapace]

Ouais me serais plutôt du genre à travailler à base de liste de peerguardian ou adblock

 

Peerguardian étant mon préféré (TMG if you know what i mean )

[John Shaft]

La liste proposée (de yoyo.org) est utilisée dans plusieurs bloqueurs de pubs, dont AdAway sur Android.

 

Ensuite, c'est pas avec résolveur DNS qui va empêcher quelqu'un de se connecter avec ton client Torrent

[Krapace]

Oui mais ya pas que ca dans les liste de Peerguardian.

 

Du coup je vais étudier un script pour extraire des listes pour convertir en ligne pour unbound. Voir même pour iptables

[John Shaft]

C'est une liste du type

 

127.0.0.1 example.org

 

Y a un script dans le lien que je filais

 

Sinon, va falloir faire du sed

[Krapace]

Ha oui...

 

Reste put qu'a trouver un script pour iptables

[John Shaft]

Aaaaah les joies iptables. J'espère que tu as aussi ip6tables à te farcir. Ça serait bête de passer à coté

[Krapace]

Surtout iptables6.

 

A terme j'aimerais éviter de me servir d'ipv4.

 

Je pense même baser mon Projet de licence sur une migration d'une entreprise de V4 ->V6 à faible coût et a base de LL.

[Tom23]

En passant, j'ai écrit un tuto sur comment monter un serveur de cache DNS avec unbound s'appuyant directement sur les serveurs racines.
(http://homeserver-diy.net/wiki/index.php?title=Installer_et_configurer_son_serveur_DNS_connecté_aux_serveurs_root_avec_Unbound)
 
J'en avait profité pour expliquer comment le faire mentir à propos des IP des régies pubs comme Krapace le cite plus haut.
En cherchant un peu j'ai trouvé une grosse liste de noms de domaines de régies pubs.
Je vous la pose là: Liste de régies pubs
 
Sinon pour partager mon expérience, j'avais installé 2 serveurs DNS. Un sur une machine locale et l'autre sur un VPS. Celui sur le VPS a rapidement été détourné pour participer à une attaque par amplification. Donc comme le dit S. Bortzmeyer, pensez à fermer vos serveurs.

[John Shaft]

Celui sur le VPS a rapidement été détourné pour participer à une attaque par amplification

 

Ouch. Pas de de contrôle d'accès ?

 

EDIT : j'ai modifié ton post, y avait des crasses dans l'encodage de caractères

[Tom23]

Ouch. Pas de de contrôle d'accès ?

Le but était de partager ce serveur avec qui le souhaitait et quelque soit le client. Je n'avais donc mis en place aucun contrôle d'accès. Les pirates en ont profité quelques heures...

[John Shaft]

Ok. J'avais eut la même idée, mais en cherchant de la doc, j'étais tombé sur l'article de Bortzmeyer et le RFC 5358

[Ricard]

@Milton pardon j'ai lu en diagonale, j'ai confondu ubuntu avec unbound ( que je ne connaissais pas ).

 

Il faut donc regarder dans le fichier unbound.conf la zone : 

forward-zone:

      name: "."

      forward-addr: 8.8.8.8        # Google Public DNS

      forward-addr: 74.82.42.42    # Hurricane Electric

      forward-addr: 4.2.2.4        # Level3 Verizon

 

C'est les dns utilisés par unbound

 

Normalement le localhost a un masque de 8 bit donc la 127.0.1.1 devrait être compris dans la plage. Un traceroute 127.0.1.1 devrait le confirmer.

Heu, alors une ipv4, c'est 32 bits, 4x8 donc. On a donc 0 pour les 8 derniers bits soit 2^8, qui nous donne: 256. En info, on commence à compter à partir de zéro, donc --> 255.

Donc, 127.0.0.254 maxi. Tu ne sors pas de la plage IP. Ton IP doit être 127.0.0.1.

Si mes souvenirs sont bons mais je peux me tromper.

[Skywa]

Oui l'IPv4 est en 32 bit mais le masque est de 8 bit :

IPv4 Table de routage
===========================================================================
Itinéraires actifs :
Destination réseau    Masque réseau  Adr. passerelle   Adr. interface Métrique
          0.0.0.0          0.0.0.0    192.168.1.254     192.168.1.74     10
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306

toutes les IP en 127.X.Y.Z sont compris dans le localhost

 

Avec un masque de 24 bit on reste dans la plage 127.0.0.0 -> 127.0.0.255

Sauf que 127.0.0.0 est réservé car désigne le réseau et la 127.0.0.255 l'adresse de broadcast donc en fait tu ne peux adresser que de 127.0.0.1 à 127.0.0.254 avec un masque de 24 bits.

 

Edit: correction des fautes d'ortho ( pas réveillé encore )

[Ricard]

Ok. J'avais eut la même idée, mais en cherchant de la doc, j'étais tombé sur l'article de Bortzmeyer et le RFC 5358

Spède de Geek.

Oui l'IPv4 est en 32 bit mais le masque est de 8 bit :

IPv4 Table de routage
===========================================================================
Itinéraires actifs :
Destination réseau    Masque réseau  Adr. passerelle   Adr. interface Métrique
          0.0.0.0          0.0.0.0    192.168.1.254     192.168.1.74     10
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306

toutes les IP en 127.X.Y.Z sont compris dans le localhost

 

Avec un masque de 24 bit on reste dans la blage 127.0.0.0 -> 127.0.0.255

Sauf que 127.0.0.0 est réservé car désigne le réseau est la 127.0.0.255 l'adresse de broadcast donc en fait tu ne peux adresser que de 127.0.0.1 à 127.0.0.254 avec un masque de 24 bits.

Oui exact. Faute de frappe. je corrige mon post.