Avec ZTDNS, Microsoft essuie les plâtres du zero trust appliqué au DNS

Les portails captifs ? L’affichage sans fil ? Le partage local des mises à jour Windows ? En l’état, tout cela ne fonctionne pas avec ZTDNS.

Sous cette bannière, Microsoft applique le principe du zero trust au DNS. Il a commencé à l’expérimenter en cercle privé.

La promesse : pouvoir bloquer les connexions sortantes en fonction des noms de domaines, sans s’appuyer sur l’interception de trafic en clair, l’inspection SNI ou des protocoles réseau propriétaires.

ZTDNS intègre deux composantes de Windows : le client DNS et la plate-forme de filtrage. Il nécessite des serveurs gérant le DNS sur HTTPS (DoH) ou sur TLS (DoT).

Par défaut, Windows bloque tout trafic IP sortant. Sauf vers ces serveurs qui ne résolvent que les noms de domaines autorisés (il laisse aussi passer le trafic DHCP et NDP nécessaire à la découverte réseau).

Les réponses des serveurs déclenchent des exceptions pour les adresses autorisées. Il est possible d’y ajouter une liste blanche « manuelle ». Et, éventuellement, d’utiliser des certificats client pour fournir des identités aux serveurs (plutôt que les adresses IP, signal moins sécurisé et peu pertinent sur les appareils nomades). En option, mTLS permet aux serveurs d’appliquer des stratégies de résolution par client.

ZTDNS ne supporte pas les portails captifs…

ZTDNS bloque tout trafic ne pouvant être associé à un nom de domaine. Cela affecte de multiples protocoles réseau, dont LLMNR, mDNS, NetBIOS, UPnP et WebRTC. On peut parfois définir les exceptions nécessaires, par exemple dans le cas d’un logiciel utilisant telle ou telle plage d’adresses IP. C’est plus compliqué dans les cas où on ne peut connaître à l’avance l’adresse IP de destination.

ZTDNS n’autorisant pas le trafic DNS en clair, les portails captifs – qui reposent pour l’essentiel sur l’interception de ce trafic – ne sont pas pris en charge à l’heure actuelle. Même chose pour les navigateurs qui utilisent leurs propres clients DNS. Avec ZTDNS, il leur faut utiliser celui de Windows. À défaut, ils ne peuvent, selon la config, procéder à la résolution ou envoyer de trafic.

Autre chose impossible en cas d’activation de ZTDNS : la découverte d’affichages sans fil. Idem pour le partage, sur réseau local, des mises à jour téléchargées via Windows Update (chaque machine devra donc se connecter au serveur).

… entre autres

Les applications de visioconférence peuvent aussi poser problème. WebRTC n’utilise effectivement pas le protocole DNS pour la découverte réseau, mais STUN (Session Traversal Utilities for NAT) et TURN (Traversal Using Relays around NAT). Il faut donc mettre en exception les sous-réseaux que communiquent les fournisseurs de ces apps.

ZTDNS peut également perturber la découverte d’imprimantes (sur mDNS). Microsoft en profite pour pousser son serveur d’impression Universal Print. Il fait de même avec SharePoint et OneDrive for Business face aux limites que ZTDNS pose en matière de découverte de partages de fichiers – notamment via la section Réseau de l’explorateur Windows.

Les technologies qui contournent la pile TCP/IP de Windows peuvent aussi contourner ZTDNS. C’est le cas de XDP (Express Data Path) et de DPDK (Data Plane Development Kit). Mais aussi de toute virtualisation implémentant sa propre stack réseau. WSL, notamment, est dans ce cas.

Illustration principale © Julien Eichinger – Fotolia