[DNS] Échapper aux DNS menteurs ?

[Milton Évantel]

Bonjour !

 

Je viens vers vous, car je ne parviens pas à comprendre quelque chose au sujet des DNS. À l’adoption de la loi dite « Terrorisme » en fin d’année dernière, j’ai installé Unbound sur mon PC pour avoir un serveur DNS local et pouvoir échapper, je pensais, aux DNS menteurs des grands opérateurs lorsque des censures de sites seraient prononcées.

 

Le problème est que cela ne suffit manifestement pas. Voyant cet article sur le blocage de t411.io, j’ai pensé que le fait de passer par mon DNS local me permettrait malgré tout d’accéder au site. Hélas, une tentative de résolution DNS me donne :

$ nslookup t411.ioServer:		127.0.1.1Address:	127.0.1.1#53Non-authoritative answer:Name:	t411.ioAddress: 127.0.0.1

Ce que je comprends donc, c’est que mon serveur DNS local est quand même menteur. Comment cela se fait-il ? Comment y échapper ?

 

Merci d’avance pour vos lumières !

[Skywa]

Salut,

 

Pourrais tu me dire dans ton fichier /etc/bind/named.conf.options qu'elle ip tu as à forwarders { X.X.X.X

Egalement dans ton fichier /etc/resolv.conf l'ip du nameserver

 

Je pense que soit ton nameserver pointe vers un dns filtré soit le forwarders n'est pas mis ou utilise également un dns filtré.

 

Sinon j'ai test quelques dns : ceux de online.net filtrent pas ni ceux de google

[Milton Évantel]

Hello, et merci pour la réponse rapide !

 

Je résous en local (j’ai installé Unbound, comme je le signalais), donc dans mon resolv.conf, mon nameserver est 127.0.1.1.

 

En revanche, je n’ai pas de dossier /etc/bind…

[Cronycs]

Tu ne t'es pas tout simplement trompé dans l'adresse? Car ce n'est pas 127.0.1.1 l'alias local, mais 127.0.0.1

[Milton Évantel]

$ cat /etc/resolv.conf# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTENnameserver 127.0.1.1

​Il me semble que localhost, c’est la plage 127.0.0.0/8…

[Cronycs]

Tout à fait, mais l'IP de l'alias local est bien le 127.0.0.1, donc si tu veux accéder à ta machine il faut saisir 127.0.0.1 et pas 127.0.1.1, qui ne correspond à aucun alias.

[Skywa]

@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.

[John Shaft]

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

 

Mieux vaut éviter de forwarder presque tout le trafic DNS sortant de sa machine vers ces gens là (peste, choléra toussa )

 

A forward-zone entry with name "." and a forward-addr target will forward all queries to that other server (unless it can answer from the cache).

https://www.unbound.net/documentation/unbound.conf.html

Si tu veux utiliser de la forward zone, utilise des résolveurs sympas :

• FDN : ns0.fdn.org (80.67.169.12 / 2001:910:800::12) | ns1.fdn.org(80.67.169.40 / 2001:910:800::40)
• LDN : ns0.ldn-fai.net (80.67.188.188 / 2001:913::8 )
• ARN : recursif.arn-fai.net (89.234.141.66 / 2a00:5881:8100:1000::3)

Source

 

C'est les dns utilisés par unbound

Unbound n'utilise pas de forward-zone par défaut. Ça ressemble à un copier/coller du (bon) tuto qui se trouve sur calomel.org

[Skywa]

Tout à fait, j'ai juste indiqué des dns en exemple, il se peut qu il ait un autre dns indiqué car sinon il aurait du interroger le root level pour le domaine io et donc le résoudre.

 

Après il se trouve que les dns google sont toujours up avec un temps de réponse très bon et n'ont pas encore bloqué de site à ma connaissance.

 

Il faut voir ce que l'on privilégie : confidentialité, rapidité, intégrité etc ... en fonction de ça choisir le bon dns.

 

N.B.: les requêtes dns étant en clair sur le réseau la confidentialité c'est un peu le dernier des pbs.

 

EDIT :

 

J'ai regardé d'un peu plus prés le domaine .io il semble que les name server du domaine ne repondent pas ce qui expliquerait pourquoi unbound ne peut pas retrouver l IP ( j ai test a,b et ns1 ) :

io        primary name server = ns1.communitydns.net        responsible mail addr = nicadmin.nic.io        serial  = 1438179730        refresh = 3600 (1 hour)        retry   = 1800 (30 mins)        expire  = 3600000 (41 days 16 hours)        default TTL = 3600 (1 hour)io      ??? unknown type 46 ???io      nameserver = a.nic.ioio      nameserver = b.nic.ioio      nameserver = b.nic.acio      nameserver = ns3.icb.co.ukio      nameserver = b.ns13.netio      nameserver = a.ns13.netio      nameserver = ns1.communitydns.net

Pour résoudre le souci pas d'autre solution que de créer une forward-zone :

forward-zone:
name: "t411.io"
forward-addr: X.Y.Z.T #Avec X.Y.Z.T l'ip ton dns de confiance

[Milton Évantel]

Salut, et merci pour vos réponses ! Je confirme que 127.0.1.1 est compris :

$ traceroute 127.0.1.1traceroute to 127.0.1.1 (127.0.1.1), 30 hops max, 60 byte packets 1  [mon pc] (127.0.1.1)  0.036 ms  0.011 ms  0.011 ms

Je ne parviens pas à comprendre ces problèmes de forward zone, par contre. Qu’est-ce qui empêche de faire en sorte qu’Unbound demande systématiquement aux serveurs ayant autorité ? J’entends par là que les solutions que vous me demandez imposent toujours de faire confiance à un autre serveur récursif… Et je comprends d’autant moins que le tuto sur Calomel.org semble expliquer qu’Unbound n’a pas a passer par des serveurs récursifs tiers…

 

Pour paramétrer Unbound, je me suis fié à un article de Korben :

$ cat /var/unbound/unbound.conf server:verbosity: 1#interface: 0.0.0.0 #Provoque un conflit…port: 53do-ip4: yesdo-ip6: yesdo-udp: yesdo-tcp: yesdo-daemonize: yes#Refuser tout le monde par défaut sauf localhostaccess-control: 0.0.0.0/0 refuseaccess-control: 127.0.0.0/8 allowchroot: "/var/unbound"username: "unbound"directory: "/var/unbound"use-syslog: yespidfile: "/var/run/unbound.pid"root-hints: "/var/unbound/named.cache"control-enable: yes

J’ai commenté la troisième ligne, si je me souviens bien, puisqu’un autre processus empêchait le lancement d’Unbound…

 

Du coup que dois-je faire ? :-)

[Skywa]

Tu peux spécifier pour quel domaine zones tu délègues le DNS :

 

forward-zone:
name: "t411.io"

 

si au lieu de t411.io tu mets . ça sera toutes les requêtes dns.

 

Dans l'exemple que je te donne :

 

forward-zone:
name: "t411.io"
forward-addr: X.Y.Z.T #Avec X.Y.Z.T l'ip ton dns de confiance

 

Seul la résolution de domaine de t411.io se fera sur le serveur X.Y.Z.T

 

Unbound n'a pas à passer par un serveur tiers à condition que les nameserver faisant autorité répondent ce qui n'est pas le cas pour ce domaine ( filtrage geo au niveau des serveurs/pb de config/saturation du serveur/etc .. )

[Milton Évantel]

D’accord, je comprends : je ne devrais en théorie pas avoir ce problème avec des noms de domaines autres que les .io ?

En ce cas, ne faudrait-il pas forwarder carrément tous les domaines en .io. ?

Et encore mieux : serait-il possible de faire en sorte qu’Unbound délègue systématiquement à un DNS de confiance les requêtes pour lesquelles le DNS du TLD ne répond pas, et aucune autre ?

[John Shaft]

A ma connaissance, Unbound ne le fait pas.

Il y a une option dans resolv.conf qui permet de passer sur un autre résolveur si la réponse à une requête met trop de temps pour arriver

[Milton Évantel]

Donc si j’ajoute à mon unbound.conf :

forward-zone:	name: "."	forward-addr: 80.67.169.12 #French Data Network ns0.fdn.org	forward-addr: 80.67.169.40 #FDN ns1.fdn.org	forward-addr: 80.67.188.188 #Lorraine Data Network ns0.ldn-fai.net, port par défaut	forward-addr: 80.67.188.188@9000 #LDN sur port 9000, pour les réseaux à DNS filtré	forward-addr: 80.67.188.188@80 #Idem	forward-addr: 89.234.141.66 #Alsace Réseau Neutre recursif.arn-fai.net	forward-first: yes

Toutes les requêtes DNS qui ne parviennent pas à être résolues directement seront forwardées d’abord à FDN, puis à LDN (en essayant les différents ports qu’ils proposent, d’après la donc), et enfin à ARN ? En sachant que par défaut, les requêtes seront faites aux serveurs ayant autorité si cela marche ? Au passage, je mets plutôt les IPv4 ou les IPv6 des serveurs auxquels je forwarde ?

 

Et question subsidiaire : comment puis-je afficher le cache d’Unbound ? Lorsque je demande à dumper le cache, j’ai une erreur que je ne parviens pas à comprendre :

$ sudo unbound-control dump_cache[1438184448] unbound-control[3092:0] warning: control-enable is 'no' in the config file.error: Error setting up SSL_CTX client key and cert140353778628256:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: CERTIFICATE140353778628256:error:140AD009:SSL routines:SSL_CTX_use_certificate_file:PEM lib:ssl_rsa.c:491:

En sachant, d’ailleurs, que control-enable est bien à yes, ce qui est assez étrange…

[John Shaft]

J'ai édité mon message, car en fait la définition du forward-first n'est pas claire (la phrase est mal tournée). En fait ça me semble plus faire le contraire : si la forward address foire, il tente sans la clause forward. Si un spécialiste peut confirmer

Bizarre pour control-enable. Tu as passé le paramètre à yes dans le fichier de conf ou tu a laissé la valeur par défaut (qui est yes) ?

[Milton Évantel]

Étrange… je vais faire des tests.

Oui, je l’ai explicitement passé à yes, cf. quelques posts plus tôt…

[Skywa]

Peux tu vérifier que tu n'as pas un /etc/unbound/unbound.conf ? Apparement sur ubuntu il installe 2 fichiers de conf.

 

Concernant le forward-first s'il est sur yes il va d'abord interroger les dns spécifiés et si pas de réponse interrogera les serveurs root - sauf pour le domaine root (.) dans les versions anciennes ( actuellement je ne sais pas si ça fonctionne il faudrait test en mettant un serveur dns bidon et demander une résolution sur un .com connu ).

 

Il faudrait juste modifier pour la zone io. ou t411.io de cette façon tu auras 99% de tes requêtes qui se feront sur les root serveurs et la résolution du t411.io qui sera bonne

[Milton Évantel]

$ cat /etc/unbound/unbound.confcat: /etc/unbound/unbound.conf: Aucun fichier ou dossier de ce type

Et si je passe explicitement forward-first à no ?

[John Shaft]

Concernant le forward-first s'il est sur yes il va d'abord interroger les dns spécifiés et si pas de réponse interrogera les serveurs root

 

Ok, c'est donc bien l'anglais des néerlandais qui développe le soft qui est tarabiscoté (ou ma fatigue)

[Skywa]

Si tu passes le forward first à no il interrogera les dns spécifiés et n'ira pas chercher plus loin si pas de réponse ( cad il n'ira pas voir les root servers )

 

Ouais la traduction en anglais est spécial, j aurais plus vu une option du style forward failover

[Milton Évantel]

J’ai donc rajouté :

forward-zone:	name: "io."	forward-addr: 80.67.169.12 #French Data Network ns0.fdn.org	forward-addr: 80.67.169.40 #FDN ns1.fdn.org	forward-addr: 80.67.188.188 #Lorraine Data Network ns0.ldn-fai.net, port par défaut	forward-addr: 80.67.188.188@9000 #LDN sur port 9000, pour les réseaux à DNS filtré	forward-addr: 80.67.188.188@80 #Idem	forward-addr: 89.234.141.66 #Alsace Réseau Neutre recursif.arn-fai.net

Et j’ai supprimé la ligne control-enable qui provoque une erreur fatale au démarrage d’Unbound, pour une raison que je ne parviens pas à comprendre avant de redémarrer Unbound (sudo service unbound restart).

 

Problème, ça ne change rien… Je suppose qu’il faut que je purge le cache ? Mais comment faire sans control-enable ?

[Skywa]

Je viens de tester le dns ns0.fdn.org il fait bien la résolution.

 

Regarde dans les logs si tu vois quelque chose : grep -R unbound /var/log/*

 

Réactive aussi le control-enable et ensuite fait un :

 

sudo unbound-control - c /chemin/du/fichier/de/conf dump_cache

[John Shaft]

Je suppose qu’il faut que je purge le cache

 

 

Le cache est purgé quand tu redémarres le service

[Jaskier]

Petite question, je viens de lire le poste, et pourquoi vous voulez absolument forwarder la zone . ?

Y'a pas besoin, unbound sait très bien interroger les serveurs racines pour chaque requête. D'ailleurs, c'est même la configuration par défaut dans pfSense depuis la 2.2.1.

 

Si jamais ça intéresse du monde, voila ce que ça donne sous pfSense.

##########################
# Unbound Configuration
##########################

##
# Server configuration
##
server:

chroot: /var/unbound
username: "unbound"
directory: "/var/unbound"
pidfile: "/var/run/unbound.pid"
use-syslog: yes
port: 53
verbosity: 1
hide-identity: yes
hide-version: yes
harden-glue: yes
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
do-daemonize: yes
module-config: "validator iterator"
unwanted-reply-threshold: 0
num-queries-per-thread: 512
jostle-timeout: 200
infra-host-ttl: 900
infra-cache-numhosts: 10000
outgoing-num-tcp: 10
incoming-num-tcp: 10
edns-buffer-size: 4096
cache-max-ttl: 86400
cache-min-ttl: 0
harden-dnssec-stripped: yes
msg-cache-size: 4m
rrset-cache-size: 8m

num-threads: 2
msg-cache-slabs: 2
rrset-cache-slabs: 2
infra-cache-slabs: 2
key-cache-slabs: 2
outgoing-range: 4096
#so-rcvbuf: 4m
auto-trust-anchor-file: /var/unbound/root.key
prefetch: yes
prefetch-key: no
use-caps-for-id: no
# Statistics
# Unbound Statistics
statistics-interval: 0
extended-statistics: yes
statistics-cumulative: yes

# Interface IP(s) to bind to
interface: 192.168.2.1
interface: 192.168.3.1
interface: 127.0.0.1
interface: ::1



# DNS Rebinding
# For DNS Rebinding prevention
private-address: 10.0.0.0/8
private-address: 172.16.0.0/12
private-address: 169.254.0.0/16
private-address: 192.168.0.0/16
private-address: fd00::/8
private-address: fe80::/10


# Access lists
include: /var/unbound/access_lists.conf

# Static host entries
include: /var/unbound/host_entries.conf

# dhcp lease entries
include: /var/unbound/dhcpleases_entries.conf

# Domain overrides
include: /var/unbound/domainoverrides.conf


# Unbound custom options
server:
private-domain: "myfabulousdomain.lan"


###
# Remote Control Config
###
include: /var/unbound/remotecontrol.conf

D'ailleurs, si je ne m'abuse, c'est la ligne auto-trust-anchor-file: /var/unbound/root.key qui s'occupe de contacter les serveurs racines.

 

Si ça peut aider quelqu'un...

 

PS: Ceci dit, je peux me viander complètement, je suis pas un expert unbound. D'ailleurs, faut que je me penche vraiment dessus, je suis en train d'adapter un script Ansible pour le déployer sur mon Kimsufi, quelle que soit la technique de virtualisation (et c'est pas le choix qui manque).

[John Shaft]

ligne auto-trust-anchor-file: /var/unbound/root.key

 

Ce fichier contient la signature dnssec de la racine. A utiliser si tu veux que ton résolveur soit validant (très chaudement recommandé)

 

C'est le paramètre

root-hints: "/chemin/root.hints"

qui donne l'adresse des serveurs de la racine