Salta el contingut

Teoria del DNS

Introducció al DNS

Què és el DNS?

El Domain Name System (DNS) és un servei fonamental d'Internet que actua com el "llistat telefònic d'Internet", traduint noms de domini llegibles pels humans (com ara google.com) en adreces IP numèriques (com ara 142.250.185.78) que les màquines poden entendre i utilitzar per comunicar-se entre elles.

Sense DNS, hauríem de recordar les adreces IP numèriques de cada lloc web que volguéssim visitar, quelcom pràcticament impossible en l'Internet actual amb milions de llocs web disponibles. Aquest sistema distribuït i jeràrquic permet que Internet funcioni de manera eficient i escalable.

Per recordar

El DNS no xifra ni protegeix les consultes per defecte: tradueix noms a IPs en text pla. Les variants xifrades (DoH, DoT) i l'autenticació de registres (DNSSEC) són capes de seguretat que s'hi afegeixen a sobre, no característiques del DNS "clàssic".

Per què és important el DNS?

La importància del DNS radica en diversos factors crítics per al funcionament d'Internet i les xarxes corporatives. En primer lloc, proporciona una capa d'abstracció entre els usuaris i la infraestructura tècnica subjacent, permetent que els usuaris utilitzin noms memorables en lloc de números complexos.

A més, el DNS és essencial per a la redundància i l'equilibri de càrrega. Un mateix nom de domini pot resoldre's a múltiples adreces IP, permetent distribuir el trànsit entre diversos servidors i proporcionar alta disponibilitat. També facilita la mobilitat dels serveis, ja que podem canviar l'adreça IP d'un servidor sense que els usuaris hagin de modificar res.

Història i Evolució del DNS

Els Orígens: ARPANET i el fitxer HOSTS

Fitxer hosts

A Windows es pot trobar el fitxer de hosts al directori %SYSTEMROOT%\drivers\etc\hosts A Linux es pot trobar a /etc/hosts

Abans del DNS, a principis dels anys 70, ARPANET (el precursor d'Internet) utilitzava un sistema molt simple per a la resolució de noms. Cada ordinador mantenia un fitxer local anomenat HOSTS.TXT que contenia una llista de tots els ordinadors de la xarxa amb les seves adreces IP corresponents.

Aquest fitxer es mantenia centralment al Stanford Research Institute (SRI) i els administradors de sistemes havien de descarregar-lo regularment via FTP per mantenir les seves còpies actualitzades. A mesura que ARPANET creixia, aquest sistema es va tornar insostenible per diversos motius: el fitxer creixia exponencialment, la càrrega al servidor central era enorme, i mantenir la consistència entre totes les còpies era pràcticament impossible.

El naixement del DNS (1983-1987)

Paul Mockapetris va desenvolupar el DNS el 1983 a la University of Southern California com a solució als problemes del sistema HOSTS.TXT. Les especificacions originals es van publicar als RFC 882 i 883 el novembre de 1983, posteriorment substituïts pels RFC 1034 i 1035 el 1987, que encara són la base del DNS actual.

El nou sistema introduïa conceptes revolucionaris com la jerarquia de dominis, la delegació d'autoritat, i la resolució distribuïda. Això permetia que cada organització gestionés el seu propi espai de noms sense dependre d'una autoritat central per a cada canvi.

BIND: La implementació de referència

BIND (Berkeley Internet Name Domain) és la implementació més antiga i utilitzada del protocol DNS, desenvolupada originalment a la University of California Berkeley. La primera versió de BIND es va llançar el 1984 com a part del sistema operatiu BSD 4.3.

BIND 9, llançat el 2000, va ser una reescriptura completa del programari per millorar la seguretat, l'escalabilitat i afegir suport per a IPv6 i DNSSEC. Actualment, BIND continua sent el servidor DNS més desplegat a Internet, utilitzat tant per servidors arrel com per grans proveïdors de serveis.

El naixement d'ICANN (1998)

Durant els anys 80 i 90, la gestió dels noms de domini i adreces IP estava força centralitzada. L'IANA (Internet Assigned Numbers Authority), dirigida per Jon Postel a la Universitat del Sud de Califòrnia (USC/ISI), era qui coordinava manualment moltes d'aquestes tasques. Però amb l'explosió d'Internet als 90, aquest model ja no era sostenible:

  • Cada vegada hi havia més dominis i més usuaris.
  • Empreses privades (com Network Solutions) havien obtingut contractes per gestionar registres de dominis, i això generava tensions sobre competència i preus.
  • El govern dels Estats Units, a través del Departament de Comerç, encara tenia un paper molt fort en la governança d'Internet, cosa que altres països i actors volien internacionalitzar.

Per això, el 1998 es va crear l'ICANN (Internet Corporation for Assigned Names and Numbers), una entitat sense ànim de lucre establerta a Califòrnia, amb la missió de gestionar aquestes funcions de manera més oberta, transparent i global.

Funcions principals d'ICANN

ICANN no controla Internet, però sí que administra les peces bàsiques que la fan funcionar de manera única i coherent:

  • Gestió del sistema de noms de domini (DNS)

    • Coordina els TLD (Top-Level Domains) com .com, .org, .net, i també els de codi de país (.es, .cat, .fr…).
    • Acredita i regula els registradors de dominis (empreses com GoDaddy, Namecheap, etc.).

  • Assignació d'adreces IP i recursos d'Internet

    • Supervisa la distribució global dels blocs d'adreces IPv4 i IPv6. Ho fa a través dels RIRs (Regional Internet Registries) com RIPE NCC (Europa), ARIN (Amèrica del Nord), APNIC (Àsia-Pacífic), etc.

  • Gestió del sistema de servidors arrel del DNS

    • Coordina els 13 servidors arrel lògics (A–M).
    • S'assegura que hi hagi coherència i seguretat en la jerarquia global de noms.

  • Polítiques de governança d'Internet

    • Facilita processos oberts i participatius on comunitats tècniques, empreses, governs i usuaris debaten i defineixen regles sobre dominis, noves extensions (.app, .shop, etc.), seguretat, i privacitat.

  • Seguretat i estabilitat

    • Promou protocols com DNSSEC per protegir la integritat de les respostes DNS.
    • Vetlla perquè Internet continuï sent estable i interoperable arreu del món.

Evolució

timeline
    title Evolució dels Protocols de Resolució de Noms
    1980s : NetBIOS Name Resolution
          : WINS (1993)
    1990s : DNS esdevé estàndard
          : LMHOSTS
    2000s : LLMNR (Windows Vista)
          : mDNS (Bonjour)
    2010s : Microsoft recomana deprecar WINS
          : DNS sobre HTTPS (DoH)
    2020s : DNS sobre TLS (DoT)
          : DNSSEC

Arquitectura i Funcionament del DNS

Utilització de ports

Tipus de tràfic Port Protocol Ús
Consultes i respostes estàndard 53 UDP La majoria de consultes DNS normals (resolució ràpida)
Transferència de zona 53 TCP Quan el servidor envia zones completes a un altre servidor (AXFR/IXFR)
Consultes grans / fragments 53 TCP Si la resposta UDP excedeix els 512 bytes (o 1232 bytes amb EDNS0)

Estructura Jeràrquica

El DNS s'organitza en una estructura d'arbre invertit amb diversos nivells. Al cim de la jerarquia trobem el domini arrel (root), representat per un punt (.). Sota l'arrel hi ha els dominis de primer nivell (TLD — Top Level Domains) com .com, .org, .es, .cat, etc.

flowchart TD;
A[.] --> B[.com];
A --> C[.org];
A --> D[.es];
D --> E[exemple.es];
E --> F[www.exemple.es];

Cada nivell de la jerarquia delega l'autoritat sobre els seus subdominis al nivell inferior. Per exemple, el TLD .es delega l'autoritat sobre exemple.es a l'organització que ha registrat aquest domini. Aquesta delegació permet una gestió distribuïda i escalable del sistema global de noms.

Per ampliar: Glue Records

Quan el servidor de noms d'un domini està dins del mateix domini que delega (per exemple, ns1.exemple.cat és el NS de exemple.cat), calen glue records: registres A/AAAA afegits directament a la zona pare perquè el resolver pugui trobar la IP del servidor de noms sense caure en un bucle de dependència circular.

Components del Sistema DNS

El sistema DNS consta de diversos components clau que treballen conjuntament:

Servidors DNS Recursius (Resolvers): Aquests servidors reben consultes dels clients i s'encarreguen de trobar la resposta navegant per la jerarquia DNS. Mantenen una memòria cau (cache) de les respostes per millorar el rendiment i reduir la càrrega a la xarxa. Son els servidors que utilitzen els usuaris finals (normalment els del teu ISP o serveis com Google DNS 8.8.8.8 o Cloudflare 1.1.1.1)

Servidors DNS Autoritatius: Contenen la informació autoritativa sobre una zona DNS específica. Quan un servidor és autoritatiu per a una zona, les seves respostes es consideren definitives per a aquell domini.

  • Respostes autoritàries → provenen directament d'un servidor que gestiona la zona.
  • Respostes no autoritàries → provenen de la cache d'un servidor recursiu.

Servidors Arrel (Root Servers): Són els servidors al cim de la jerarquia DNS. Actualment hi ha 13 adreces IP de servidors arrel (anomenades A-M), encara que físicament són centenars de servidors distribuïts globalment utilitzant anycast.

Servidors de domini de primer nivell (TLD servers): Contenen la informació dels dominis d'un TLD concret (per exemple, .com, .org, .es, .cat). Quan un recursiu pregunta per www.exemple.cat, el servidor .cat li diu quins són els autoritatius per exemple.cat.

Zona i registres DNS (namespace): Una zona DNS és la part de l'espai de noms que un servidor autoritatiu administra.

Caches DNS: Tant els resolvers com els sistemes operatius i navegadors mantenen una cache local. Eviten repetir consultes i milloren el rendiment. Cada registre té un TTL (Time To Live) que marca quant de temps pot romandre en cache.

Compte amb el TTL

Un TTL massa alt fa que els canvis (per exemple, canviar la IP d'un servidor) triguin a propagar-se; un TTL massa baix augmenta la càrrega de consultes. Abans de migrar un servei, baixa el TTL amb antelació perquè el canvi es propagui ràpid quan arribi el moment.

Procés de Resolució DNS

Quan un usuari introdueix una URL al navegador, s'inicia un procés complex de resolució que segueix aquests passos:

flowchart TD
    U[Usuari] --> R[Resolver recursiu]
    R --> A[Servidors arrel]
    A --> T[TLD .com / .es / .org]
    T --> Z[Servidor autoritatiu]
    Z -->|Resposta definitiva| R
    R --> U

  1. Consulta al resolver local: El sistema operatiu primer consulta la seva cache local i el fitxer hosts. Si no troba la resposta, envia la consulta al servidor DNS configurat (normalment el del proveïdor d'Internet).

  2. Resolució recursiva: Si el resolver no té la resposta a la seva cache, inicia una resolució recursiva començant pels servidors arrel, després els TLD, i finalment els servidors autoritatius del domini.

  3. Emmagatzematge en cache: Cada resposta s'emmagatzema temporalment segons el seu TTL (Time To Live) per accelerar futures consultes.

  4. Retorn de la resposta: Finalment, l'adreça IP es retorna a l'aplicació que la va sol·licitar.

AC0375/01/01 — Miniactivitat

RA1 · CA1a

Obre Wireshark (o tcpdump) i captura el trànsit mentre resols un nom de domini que no tinguis en cache (nslookup nomqualsevol.cat o dig +trace nomqualsevol.cat). Identifica els paquets de consulta i resposta DNS: quin port fan servir, quin tipus de registre es demana i en quin ordre apareixen els servidors (arrel, TLD, autoritatiu).

Tipus de Registres DNS

Registres Bàsics

Registre A (Address): Mapeja un nom de domini a una adreça IPv4. És el tipus de registre més comú i fonamental. Per exemple: www.exemple.cat IN A 192.0.2.1

Registre AAAA: Similar al registre A però per a adreces IPv6. Exemple: www.exemple.cat IN AAAA 2001:db8::1

Registre CNAME (Canonical Name): Crea un àlies d'un nom a un altre. Útil per apuntar múltiples noms al mateix servidor. Exemple: ftp.exemple.cat IN CNAME www.exemple.cat

Registre MX (Mail Exchange): Especifica els servidors de correu per al domini, incloent una prioritat. Exemple: exemple.cat IN MX 10 mail.exemple.cat

Registres Avançats

Registre NS (Name Server): Indica quins servidors DNS són autoritatius per a una zona. Fonamental per a la delegació de subdominis.

Registre PTR (Pointer): Utilitzat per a la resolució inversa (d'IP a nom). Essencial per a la verificació de servidors de correu.

Registre SOA (Start of Authority): Conté informació administrativa sobre la zona, incloent el servidor primari, el correu de l'administrador, i diversos temporitzadors per a la sincronització.

Registre TXT: Permet emmagatzemar text arbitrari. Utilitzat per SPF, DKIM, verificació de domini, i altres propòsits.

Registre SRV (Service): Especifica la ubicació de serveis específics, incloent port i prioritat. Utilitzat per protocols com SIP, XMPP, i Active Directory.

Registre CAA (Certification Authority Authorization): Especifica quines autoritats de certificació poden emetre certificats SSL per al domini.

DNS Secundari i Replicació

Un servidor DNS secundari manté una còpia de només lectura de les zones d'un servidor primari. Això proporciona redundància i millora el rendiment distribuint la càrrega de consultes.

El servidor secundari sincronitza periòdicament les seves dades amb el primari mitjançant transferències de zona. La configuració pràctica d'un servidor secundari es tracta a les pàgines d'instal·lació de Linux i de Windows.

Diferències entre DNS Iteratiu i DNS Recursiu

Els servidors DNS poden gestionar les consultes de dues maneres diferents: recursiva i iterativa. La diferència principal radica en qui és responsable de resoldre completament el nom de domini.

Consulta DNS Recursiva

En una consulta recursiva, el servidor DNS assumeix la responsabilitat completa de resoldre el nom de domini. El client fa una única petició i espera una resposta definitiva (IP o error). Presenta les següents característiques:

  • El servidor DNS fa totes les consultes necessàries en nom del client
  • El client només envia una petició i rep una resposta final
  • El servidor contacta amb altres servidors DNS si és necessari
  • Consumeix més recursos al servidor DNS
  • És el tipus de consulta que fan els clients finals (ordinadors, mòbils, etc.)

El procés que segueix és:

Client                 Resolver DNS              Arrel    TLD (.com)   Autoritatiu
  |                         |                       |          |             |
  |--1. Consulta recursiva->|                       |          |             |
  |   www.example.com       |                       |          |             |
  |                         |--2. Consulta iter.--->|          |             |
  |                         |<-3. Ref. TLD .com-----|          |             |
  |                         |                       |          |             |
  |                         |--4. Consulta iter.------------>  |             |
  |                         |<-5. Ref. example.com-------------|             |
  |                         |                       |          |             |
  |                         |--6. Consulta iter.------------------------->   |
  |                         |<-7. IP 93.184.216.34---------------------------|
  |                         |                       |          |             |
  |<-8. Resposta recursiva--|                       |          |             |
  |   IP: 93.184.216.34     |                       |          |             |
  1. El client envia una consulta recursiva al servidor DNS resolver
  2. El resolver cerca en la seva cache
  3. Si no troba la resposta, el resolver inicia consultes iteratives cap als servidors autoritatius
  4. El resolver retorna la resposta final al client (IP o NXDOMAIN)

Consulta DNS Iterativa

En una consulta iterativa, el servidor DNS proporciona la millor resposta que té disponible en aquell moment. Si no coneix la resposta final, retorna una referència a un altre servidor DNS més proper a la resposta. Presenta les següents característiques:

  • El servidor DNS retorna la millor informació disponible o una referència
  • El client (o resolver) ha de fer múltiples consultes seguint les referències
  • Consumeix menys recursos al servidor DNS individual
  • És el tipus de consulta que fan els resolvers DNS entre servidors autoritatius

El procés que segueix és:

Client                 Arrel              TLD (.com)        Autoritatiu
  |                      |                     |                  |
  |--1. www.example.com->|                     |                  |
  |<-2. Ref: TLD .com----|                     |                  |
  |                      |                     |                  |
  |--3. www.example.com---------------->       |                  |
  |<-4. Ref: ns.example.com-------------------|                  |
  |                      |                     |                  |
  |--5. www.example.com-------------------------------------->    |
  |<-6. IP: 93.184.216.34-------------------------------------|    |
  1. El resolver envia una consulta iterativa al servidor arrel
  2. El servidor arrel respon amb una referència als servidors TLD
  3. El resolver consulta el servidor TLD
  4. El servidor TLD respon amb una referència al servidor autoritatiu
  5. El resolver consulta el servidor autoritatiu
  6. El servidor autoritatiu retorna la resposta definitiva

Comparativa

Característica DNS Recursiu DNS Iteratiu
Responsabilitat El servidor DNS resol completament la consulta El client segueix les referències fins trobar la resposta
Nombre de consultes del client 1 consulta Múltiples consultes
Càrrega del servidor Alta (fa totes les consultes) Baixa (només retorna referències)
Ús de cache Sí, emmagatzema respostes Normalment no
Qui l'utilitza Clients finals → Resolver Resolver → Servidors autoritatius
Velocitat percebuda Més ràpida per al client Més lenta per al client
Amplada de banda Menor del client Major del client

Truc per no confondre'ls

Client → Resolver = recursiu (el client vol una resposta definitiva, "fes-ho tu per mi"). Resolver → Servidors autoritatius = iteratiu (el resolver va saltant de referència en referència).

AC0375/01/02 — Miniactivitat

RA1 · CA1b

Des d'un equip Linux, executa dig www.google.com i dig +trace www.google.com. Des d'un equip Windows, executa nslookup www.google.com i Resolve-DnsName www.google.com. Compara les sortides: quina informació dona cada eina, i quina mostra explícitament el camí de resolució iteratiu?

DNS en Entorns Cloud i Contenidors

DNS en Kubernetes

Kubernetes utilitza CoreDNS com a servidor DNS per defecte, proporcionant resolució de noms per a serveis i pods.

Exemple de configuració de CoreDNS:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health {
           lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf {
           max_concurrent 1000
        }
        cache 30
        loop
        reload
        loadbalance
    }

DNS en Docker

Docker utilitza un servidor DNS embedded per a la resolució de noms entre contenidors:

Cal xarxa pròpia

El DNS embedded de Docker només funciona entre contenidors connectats a la mateixa xarxa definida per l'usuari (docker network create). A la xarxa bridge per defecte, els contenidors no es resolen pel nom, només per IP.

# Crear xarxa personalitzada amb DNS
docker network create --driver bridge \
    --subnet=172.20.0.0/16 \
    --opt "com.docker.network.bridge.name"="docker-dns" \
    mynetwork

# Executar contenidor amb DNS personalitzat
docker run -d \
    --name myapp \
    --network mynetwork \
    --dns 8.8.8.8 \
    --dns-search exemple.local \
    nginx

DNS com a Servei (DNS-as-a-Service)

Molts proveïdors cloud ofereixen serveis DNS gestionats:

  • AWS Route 53: Servei DNS altament disponible i escalable
  • Azure DNS: Integrat amb els serveis de Microsoft Azure
  • Google Cloud DNS: DNS global amb baixa latència
  • Cloudflare DNS: Conegut per la seva velocitat i seguretat

Compliment Normatiu i Estàndards

RFCs Principals

Els Request for Comments (RFCs) són els documents que defineixen els estàndards d'Internet. Els més importants per a DNS són:

  • RFC 1034 i 1035 (1987): Definicions bàsiques del DNS
  • RFC 2181 (1997): Clarificacions sobre l'especificació DNS
  • RFC 2308 (1998): Negative caching
  • RFC 4033-4035 (2005): DNSSEC
  • RFC 6891 (2013): Extension Mechanisms for DNS (EDNS)
  • RFC 7858 (2016): DNS over TLS (DoT)
  • RFC 8484 (2018): DNS over HTTPS (DoH)
  • RFC 9250 (2022): DNS over QUIC (DoQ)

Error comú d'examen: DNSSEC no xifra

DNSSEC garanteix autenticitat i integritat (signa els registres perquè no es puguin falsificar), però no xifra les consultes: qualsevol pot seguir veient què consultes. Per confidencialitat cal DoH o DoT. Són capes complementàries, no substitutives.

Compliment GDPR

Sota el GDPR, les consultes DNS poden contenir dades personals. Recomanacions:

  • Minimitzar el logging de consultes DNS
  • Anonimitzar adreces IP als logs
  • Establir periódes de retenció curts
  • Xifrar les comunicacions DNS (DoH/DoT)

A Espanya, a més del GDPR

Cal tenir en compte també la LOPDGDD (Llei Orgànica 3/2018), que complementa el GDPR a nivell estatal amb aspectes com el dret a l'oblit o la regulació addicional del tractament de dades a les administracions públiques.

La traçabilitat de la navegació

Casos d'Ús i Escenaris Pràctics

DNS per a Active Directory

Active Directory depèn completament del DNS per al seu funcionament:

# Zones necessàries per AD
_msdcs.domini.local
_sites.domini.local
_tcp.domini.local
_udp.domini.local

Per què .local per als dominis interns?

Als exemples d'aquest curs (i en molts entorns corporatius) es fa servir el sufix .local per als dominis interns/de laboratori (empresa.local, domini.local...). No és arbitrari: .local no és un TLD registrable a Internet, sinó que està reservat per l'RFC 6762 (Multicast DNS) exclusivament per a la resolució de noms sense servidor a la xarxa local (mDNS / Bonjour / Zeroconf / Avahi). Fer-lo servir per a una zona interna garanteix que mai col·lidirà amb un domini públic real.

Però compte: aquesta mateixa reserva és la raó per la qual .local no es recomana per a un domini d'Active Directory de producció: sistemes operatius com macOS o Linux (Avahi) intenten resoldre .local per mDNS abans que per DNS unicast normal, cosa que pot provocar conflictes de resolució i lentitud intermitent. La pràctica recomanada avui dia és fer servir un subdomini d'un domini que ja posseeixis i tinguis registrat (per exemple corp.empresa.cat) en lloc de .local. Més detalls a l'article ".local" a Wikipedia, que resumeix bé la controvèrsia.

Quan, a més, l'organització té serveis exposats en una DMZ, cal un disseny encara més acurat perquè la DMZ mai pugui fer servir de porta d'entrada cap a l'AD — vegeu la configuració recomanada a DNS d'Active Directory quan hi ha una DMZ.

DNS per a Serveis de Correu

Configuració completa per a un servidor de correu:

# Registres necessaris
@           IN  MX  10  mail.exemple.cat.
mail        IN  A       203.0.113.10
@           IN  TXT     "v=spf1 mx -all"
_dmarc      IN  TXT     "v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.cat"
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

DNS per a Balanceig de Càrrega

Utilitzar múltiples registres A per distribuir trànsit:

www         IN  A   203.0.113.10
www         IN  A   203.0.113.11
www         IN  A   203.0.113.12

Tendències Futures

DNS over HTTPS (DoH) i DNS over TLS (DoT)

Aquests protocols xifren les consultes DNS per millorar la privadesa. La configuració pràctica de DoT en BIND es tracta a la pàgina de Linux, i la configuració de DoH per al client Windows a la pàgina de Windows.

DNS sobre QUIC (DoQ)

Protocol emergent que combina els beneficis de DoH/DoT amb menor latència utilitzant QUIC.

Integració amb IA i Machine Learning

Detecció d'anomalies i predicció d'amenaces utilitzant IA, amb precisió del 96% en alguns sistemes comercials.

Referències i Recursos

Documentació oficial, llibres, eines i comunitats sobre DNS: consulta la secció DNS a la pàgina d'Annexos · Recursos.