Serveur DNS récursif ouvert

Adresses

Nous avons un serveur DNS récursif ouvert (rate-limité, supervisé) sur l’extérieur qui répond au doux nom de ns0.ldn-fai.net. Son adresse IPv6 est 2001:913::8 et son adresse IPv4 est 80.67.188.188.

Le service est disponible :

  • en UDP sur les ports 53 (standard) et 9000 ;
  • en TCP sur les ports 53 (standard) et 9000 ;
  • en TLS sur les ports 853 (standard) et 443 (le port 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 TCP ;
  • passer par TLS.

Cette dernière solution permet de plus d’éviter une écoute du flux DNS. Nous allons donc nous concentrer sur celle-ci.

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.

Attention : les nom de domaines peuvent tout de même passer en clair d’autres biais (par SNI, dans les certificats échangés par TLS, etc.).

Attention : Cela n’apporte qu’une protection relative. Un attaquant peut toujours voir :

  • 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 contenu des échanges des flux non chiffrés (et peut les modifier) ;
  • les noms de domaines que vous contacter en HTTP via le champs Server ;
  • les noms de domaines que vous contactez en HTTPS (ou TLS de manière générale) via l’extension SNI (qui passe en clair).

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.