Fondamentaux DNS¶

La hiérarchie DNS¶

Le DNS est un système distribue et hierarchique. Chaque nom de domaine se lit de droite a gauche, du plus général au plus spécifique :

graph LR
    app["app"] --- production["production"] --- internal["internal"] --- company["company"] --- io["io"] --- root["Racine (.)"]
    app -.- lbl1["Sous-domaine"]
    production -.- lbl2["Sous-domaine"]
    internal -.- lbl3["Domaine"]
    io -.- lbl4["TLD"]

Pour un DNS interne d'entreprise, on définit généralement un domaine prive (par exemple internal.company.io ou un domaine reserve comme .internal) qui n'est resolu que par les serveurs DNS internes.

Types d'enregistrements¶

Enregistrements SRV en detail¶

L'enregistrement SRV est fondamental pour le service discovery interne :

_service._proto.name  TTL  IN  SRV  priority  weight  port  target

# Exemples concrets
_ldap._tcp.internal.      300  IN  SRV  10  60  636  iam-1.internal.
_ldap._tcp.internal.      300  IN  SRV  10  40  636  iam-2.internal.
_kerberos._udp.internal.  300  IN  SRV  10  0   88   kdc.internal.

Les champs priority et weight permettent le load balancing et le failover : les clients contactent d'abord les serveurs de priorité la plus basse, et repartissent la charge selon les poids.

Résolution : recursive vs authoritative¶

sequenceDiagram
    participant C as Client
    participant R as Resolver recursif
    participant A as Serveur autoritatif
    C->>R: Requete: app.internal
    R->>A: Requete a l'autoritatif
    A->>R: Reponse: 10.30.1.42
    Note over R: Mise en cache
    R->>C: Reponse: 10.30.1.42

DNS interne vs DNS public¶

Split-horizon DNS¶

Le split-horizon permet de repondre differemment selon l'origine de la requête :

graph LR
    CI["Client interne"] --> DNS["DNS interne<br/>(split-horizon)"]
    VPN["Client VPN"] --> DNS
    Ext["Client Internet"] --> DNS
    DNS -->|Client interne/VPN| Priv["10.30.1.42<br/>(IP privee)"]
    DNS -->|Client Internet| Pub["203.0.113.42<br/>(IP publique)"]

Cas d'usage : un service comme api.company.io résout vers l'IP privee pour les clients internes (performance, pas de NAT hairpin) et vers l'IP publique pour les clients externes.

TTL et caching¶

Le TTL (Time To Live) définit combien de temps un enregistrement est cache :

Service discovery¶

Le DNS est le mécanisme de service discovery le plus universel. Deux approches dominent :

Kubernetes CoreDNS¶

Dans un cluster Kubernetes, CoreDNS résout automatiquement les noms de services :

# Service dans le namespace "production"
app-api.production.svc.cluster.local  →  10.96.42.10

# Headless service (resolution vers les pods individuels)
pod-0.app-api.production.svc.cluster.local  →  10.244.1.15
pod-1.app-api.production.svc.cluster.local  →  10.244.2.23

Consul DNS¶

HashiCorp Consul expose un DNS de service discovery :

# Service enregistre dans Consul
app-api.service.consul         →  10.30.1.42, 10.30.1.43
app-api.service.dc1.consul     →  10.30.1.42 (datacenter specifique)

# Health-checked : seuls les services sains sont retournes

Comparaison des approches¶

DNS-over-TLS et DNS-over-HTTPS¶

Le DNS classique (port 53/UDP) transmet les requêtes en clair. Pour protéger la confidentialite :

Synthese¶

Le DNS interne est un service invisible mais critique. Une panne DNS paralyse l'ensemble de l'infrastructure. Les chapitres suivants detaillent le choix de solution, l'architecture, le déploiement et les bonnes pratiques pour un service DNS resilient.