Serveur DNS récursif ouvert

CE SERVICE N’EST PLUS DISPONIBLE !

⚠️ Fin de service. Suite à la décision de dissolution de l’association, notre service DNS récursif ouvert a été fermé le 25 août 2022.

À terme, les adresses IPs associées seront réallouées à d’autres organisations. Nous vous invitons à prendre vos dispositions afin de ne plus utiliser ce service dès à présent. Vous pouvez consulter la liste des résolveurs publiques recensés sur le site de DNS privacy.

Adresses

Nous avions un serveur DNS récursif ouvert (rate-limité, supervisé) sur l’extérieur qui répondait au doux nom de ns0.ldn-fai.net. Son adresse IPv6 était 2001:913::8 et son adresse IPv4 était 80.67.188.188. Il était également accessible en DNS sur HTTPS.

Le service était disponible :

  • en DNS sur UDP sur les ports 53 (standard) et 9000 ;
  • en DNS sur TCP sur les ports 53 (standard) et 9000 ;
  • en DNS sur TLS sur les ports 853 (standard) et 443 (le port HTTPS) ;
  • en DNS sur HTTPS.

Si vous êtes sur un réseau qui filtre ou censure le trafic DNS, vous pouvez donc tenter les approches suivantes :

  • utiliser le port 9000 (via PAT, socat/netcat, etc.);
  • passer en DNS sur TCP ;
  • passer par DNS sur TLS ;
  • passer en DNS sur HTTPS.

Nous allons nous concentrer sur les deux dernières solutions qui sont plus robustes à une censure au niveau réseau.

Avertissement

L’utilisation de DNS sur TLS ou DNS sur HTTPS permet dans de nombreux cas de contourner une censure au niveau DNS (DNS menteur) opérées par exemple par le FAI. Elle permet aussi dans une certaine mesure de protéger la vie privée en empêchant aux acteurs situés sur le réseau entre vous et le serveur DNS récursif utilisé de voir le contenu des requêtes DNS. Cependant, cette protection de la vie privée reste toute relative.

Un attaquant sur le réseau peut tout  de même observer passivement :

  • les nom de domaines qui peuvent tout de même passer en clair d’autres biais par exemple,
    • dans le champs SNI de TLS (qui passe en clair),
    • dans les certificats échangés (qui passent en clair)
  • les adresses IP des machines avec lesquelles vous communiquez (et tenter de un trouver un nom de domaine associé par recherche DNS inverse par exemple) ;
  • les contenus des échanges des flux non-chiffrés.

DNS sur HTTPS

  • Géré nativement par les version récentes de Firefox : il faut renseigner l’URI à utiliser dans les préférences (paramètres réseau).

DNS sur TLS

L’utilisation de DNS sur TLS permet de chiffrer les données entre votre machine et le serveur DNS LDN ce qui permet de permet d’éviter à un attaquant sur le réseau de voir le traffic DNS.

Clé publique

Le hash de la clé publique (SPKI pin) de ce  serveur est :

(SHA-256) WaG0kHUS5N/ny0labz85HZg+v+f0b/UQ73IZjFep0nM=

Le certificat actuel est :

-----BEGIN CERTIFICATE-----
MIIFYzCCA0ugAwIBAgIJAP3sZe6dzCxGMA0GCSqGSIb3DQEBCwUAMEgxCzAJBgNV
BAYTAkZSMRMwEQYDVQQIDApTb21lLVN0YXRlMQwwCgYDVQQKDANMRE4xFjAUBgNV
BAMMDTgwLjY3LjE4OC4xODgwHhcNMTYwOTI2MjI0MzMzWhcNMTgwOTI2MjI0MzMz
WjBIMQswCQYDVQQGEwJGUjETMBEGA1UECAwKU29tZS1TdGF0ZTEMMAoGA1UECgwD
TEROMRYwFAYDVQQDDA04MC42Ny4xODguMTg4MIICIjANBgkqhkiG9w0BAQEFAAOC
Ag8AMIICCgKCAgEAuIPaKHc6zgGFgdDxJPaw7hf63ytMGw0roFMlYOklC3uiFTp8
QLHA9NKTXWXEl0OBnaNerPsQpnoCR8UOf9pWKZa2kiLXQDvShsz9pHXzfLskRxOh
Fegk3m/lO7C8Hj6QI3leTm6naVdrWySaZ1K5RAx6kRwdUSZ08x/je4Vc1ZTe1Hbr
qYexvX94EJhrmIxA9u9q7RoRYAUbNR3h8QhotO6APYlsSsaDE2hkju4vjfz8/M4T
jSClvEn6Keto/UkB0Xno1jDvxxSqSansxOymha1JM5u4G95XfYKLpnebqpShGN0Y
UhUK26q8MVKCWAV6fEN4cDfofqGF+zGC/js8GyiZWP/qxuOf9QJWbs78oa0pQRS+
yO8W+F2ue0ND5gu89/VzoejfJO0MHiyl60g/548EGffCp4gCCSasV+bDbHrgctw1
8iQvnu5Thi7IbCFp7Sgfypj57Ryq/nmcipXSxxcm7g/ZP16V5+Bcy/u3JQox2OUv
WvvikbduUjN6Zx5qs5XBBVRqiqpHtyU8rHR23344ARHE+nf3XQZS+Sy9ItskAbPV
thpX33GfUslR1P9GOwBFewC64DtErqOrzyzCqWuLdBbvBGOnc9uD1hZdFJIX685O
nMkQThaiKWNFAJGL6zGyTxHAJ3Ipn3HgbpSeBLHVtA+EOLCa/ZQZYvsyVgcCAwEA
AaNQME4wHQYDVR0OBBYEFIjES3O/vxZcx1wJ3SFlhQLRz/+fMB8GA1UdIwQYMBaA
FIjES3O/vxZcx1wJ3SFlhQLRz/+fMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEL
BQADggIBAB7C5/+Ej4n4mZzvymZYqb3TgQcpTsiyqW0jQNs66e1zaI8u5Tce/tk9
X+G09CVPu7BYCgGe1t489mnUc+3AeVkw5kS7FHS/JldhV/i4pDs1b3z9FuiVvcmq
EJCOkkn2IDqvraQU3RP4356d89cz140VrR7l6dqh1bKT6C+u0Atd1HiGpyhBZvG3
9BS3qtyhLxCVUBjITvN3dK4/MLeW3oppUYvcqhusZI+XxfpML5DCLPP+MFLEFYt9
tqiwzBrbiAYH7B00h/PZRjNMdhA5jxFIKIaBM6iO6trGEC455tzMjI6OhFY5P5nE
UUjj+r8dwhpz88Lqsm6SFLqumMbSapsGdLkL4prvMz1Meph5WYetnCa9+op5xoyS
bMvae/kSOrmy43N+Zd5Uod2v9jBZsA8n87ykq+m80i2ZHG9GH654aHSTaNPptCYU
E9/YFzvwDWc9k6b0eT9rqNdgx8B4uZkNpE6kJBVCsJ38CLczqR3wawbE0cm/nkXi
Os4ifJ1NwlBMujJ7AnPXmATCTvOjiDgVkxgdnjWFjcdtv8J/iozrj6TOVvHRPGRo
RG8TjLQZWf0KtBF+dmaoujWoSt3kknWc6MSRTxMqygWL0mKsXz1xDqaIFhGY/Oau
LpOaxq75VIywhC0XSEAAnaxPBjajnU6Sixsr2EYtl9/4kQkdz+yd
-----END CERTIFICATE-----

Ce certificat est actuellement expiré ce qui ne pose pas de soucis en mode SPKI (en pratique avec Stubby) mais peut poser soucis en mode PKIX (stunnel, Unbound, etc.).

Résumé des solutions pour l’utiliser

Désormais, de nombreux logiciels gèrent nativement DNS/TLS :

  • Stubby (ne fait de pas cache tout seul)
  • Unbound
    1. ne vérifie par le certificat avant la version 1.7.1
    2. peut vérifier le certificat en mode PKIX depuis 1.7.1 (mais pas en mode SPKI)
  • Knot Resolver
  • systemd-resolved (depuis la version 239) a un mode DNS/TLS opportuniste (donc pas de protection contre une attaque MITM).

Voir le wiki de DNS privacy pour plus de détails sur la configuration.

Stubby

À l’heure actuelle, nous recommandons, Stubby qui a les avantages suivants :

  • gestion native de DNS/TLS ;
  • gestion de SPKI ;
  • n’ouvre pas une connection pour chaque nouvelle requête (ce que font d’autres implémentation et est très inefficace).

Il y a déjà des lignes (commentées) dans le fichier de configuration par défaut pour utiliser le serveur LDN.

  - address_data: 80.67.188.188
    tls_pubkey_pinset:
      - digest: "sha256"
        value: WaG0kHUS5N/ny0labz85HZg+v+f0b/UQ73IZjFep0nM=

Par contre, il a les défauts suivants :

  • pas de cache ;
  • pas de vérification DNSSEC

Pour profiter de ses fonctionnalités, il faut mettre un autre resolver (Unbound, Knot Resolver) en complément.

Unbound

Support de DNS/TLS. Aux dernières nouvelle, il utilise cependant une connection à chaque nouvelle requête ce qui n’est pas idéal en terme de performance.

À une époque il ne gérait pas la vérification de certificat. C’est maintenant résolu si on spécifie un nom de domaine à authentifier. La méthode utilisé est PKIX (méthode classique utilisée pour HTTPS). Pas de support de SPKI pour le moment.

Knot

Systemd-Resolved

Tunnel TLS

Une autre solution consiste à utiliser des logiciels qui ne gèrent du DNS/TCP (Unbound, Bind) avec un tunnel TLS (stunnel, socat). Cette approche était justifiée avant que le support de DNS/TLS ne soit répandu mais de nos jours c’est un peu du bricolage.

Et DNSSEC dans tout ça ?

La vérification DNSSEC permet de vérifier que la réponse n’a pas été modifiée/falsifiée mais ne permet pas d’empêcher la surveillance des requêtes DNS effectuées.

DNSSEC ne permet pas nons plus d’empécher une censure des informations fournies par le DNS mais seulement de vérifier leur authenticité.